Every few years, a new architectural pattern sweeps through the industry promising to solve all our problems. Microservices. Serverless. Event-driven. Each wave brings a fresh set of diagrams and conference talks — and a fresh set of systems that will be legacy before the next hype cycle arrives.
The truth is simpler and less exciting: systems survive because of discipline, not architecture patterns. The pattern matters far less than how consistently the team applies principles around boundaries, contracts, observability and change management.
1. Boundaries that reflect the business, not the org chart
The most common failure we see is boundaries drawn around teams rather than domains. When team reorganisations happen — and they will — those boundaries become actively harmful. Draw them around business capabilities instead: Billing, Identity, Fulfilment, Catalogue. Then let teams map to them, not the other way around.
2. Contracts over implementations
Every integration between two parts of your system should be a contract — versioned, documented, tested. Whether it's an HTTP API, a queue message or a database view, the contract is what you commit to keeping stable. Everything else is an implementation detail that should be free to change.
The code you write today will be read by someone who has no context on why you made these decisions. Design for them, not for yourself.
3. Observability is not optional
If you cannot answer "what is happening right now" and "what happened at 3pm last Tuesday" from your dashboards and logs, you don't have an operable system — you have a liability. Structured logging, distributed tracing, and meaningful metrics should be part of the definition of done, not an afterthought.
4. Automate everything you'll do more than twice
Deploys, migrations, environment setup, backup restores — if you'll do it more than twice, automate it. The upfront cost is always worth it, and it removes whole categories of human error that compound over years.
5. Document decisions, not just code
Code tells you what, not why. Keep architecture decision records (ADRs) that capture the context, options considered and reasoning behind significant choices. When a decision needs revisiting in three years, you'll thank yourself.
6. Plan for the team you'll have, not the team you have
Your system will outlive the tenure of most engineers who built it. Optimise for onboarding speed, clear conventions and low cognitive load — not for the cleverness of the original authors.
The bottom line
There's no architecture that guarantees longevity. But there is a set of habits — clear boundaries, stable contracts, deep observability, relentless automation and honest documentation — that dramatically improves the odds. Apply them consistently and your system will be one of the rare ones still running in a decade.